Skip to content

Conversation

@AllenZhang-NXP
Copy link
Contributor

Added board shared sram bypass first 8KB overlay.
The overlay configure shall bypass first 8KB memory to avoid being clear during system startup.
In test_wdt.c, there're three variables m_state, m_testcase_index and m_testvalue which are linked in the NOINIT_SECTION section.
And these three variables are used to store the test state and the test case index, after the watchdog reset, this case will check the value of the m_state and m_testcase_index, then add 1 to m_testcase_index and run the next test case.
I checked the memory map and found these three variables are linked to:
0x200055e8 m_testvalue
0x200055ec m_testcase_index
0x200055f0 m_state
After the watchdog trigger a reset, the memory starts from 0x20005000 ~ 0x20005BC0 will be set to 0 automatically (Confirmed it is a silicon behaviour, maybe ROM code do this).
As a result, the value of the variables will be cleared to 0. This is why this case is always reset.

Validated the commands below, hi @hakehuang, please help to double check, thank you!
west build -p=auto tests/drivers/watchdog/wdt_basic_api -b frdm_mcxw23 -T drivers.watchdog.nxp_mcxw2xx_bypass_first_8k
west build -p=auto tests/drivers/watchdog/wdt_basic_api -b mcxw23_evk -T drivers.watchdog.nxp_mcxw2xx_bypass_first_8k

Fixes #98282

@hakehuang
Copy link
Contributor

ci failure is reported #97023

@hakehuang
Copy link
Contributor

Validated the commands below, hi @hakehuang, please help to double check, thank you!
west build -p=auto tests/drivers/watchdog/wdt_basic_api -b frdm_mcxw23 -T drivers.watchdog.nxp_mcxw2xx_bypass_first_8k west build -p=auto tests/drivers/watchdog/wdt_basic_api -b mcxw23_evk -T drivers.watchdog.nxp_mcxw2xx_bypass_first_8k

twister regression test pass on v4.3.0-rc1-142-gae1af302830f

@dleach02
Copy link
Member

@AllenZhang-NXP is this because the first 8K does not get retained over resets?

We have been aware of multiple platforms where this lack of retention impacts this test case.

@AllenZhang-NXP
Copy link
Contributor Author

@AllenZhang-NXP is this because the first 8K does not get retained over resets?

We have been aware of multiple platforms where this lack of retention impacts this test case.

Hi @dleach02 , not all of the first 8KB of RAM will be cleared to 0, but at least the RAM from 0x20005000 ~ 0x20005BC0 which is used to store the noinit variables will be cleared, so I reserved the entire first 8KB.

@butok
Copy link
Contributor

butok commented Nov 3, 2025

@AllenZhang-NXP is this because the first 8K does not get retained over resets?
We have been aware of multiple platforms where this lack of retention impacts this test case.

Hi @dleach02 , not all of the first 8KB of RAM will be cleared to 0, but at least the RAM from 0x20005000 ~ 0x20005BC0 which is used to store the noinit variables will be cleared, so I reserved the entire first 8KB.

Boot ROM typically claims the first portion of RAM as its workspace during startup. So even if you store data in the first KB for retention, Boot ROM will overwrite/clear it on next power cycle. Ask ROM team for concrete addresses/sizes.

@AllenZhang-NXP
Copy link
Contributor Author

@AllenZhang-NXP is this because the first 8K does not get retained over resets?
We have been aware of multiple platforms where this lack of retention impacts this test case.

Hi @dleach02 , not all of the first 8KB of RAM will be cleared to 0, but at least the RAM from 0x20005000 ~ 0x20005BC0 which is used to store the noinit variables will be cleared, so I reserved the entire first 8KB.

Boot ROM typically claims the first portion of RAM as its workspace during startup. So even if you store data in the first KB for retention, Boot ROM will overwrite/clear it on next power cycle. Ask ROM team for concrete addresses/sizes.

Hi @butok, I asked ROM team (Karl Verheyden) and got the reply:
The Boot ROM uses the first 32KB of the RAM during boot. Only the first 16KB is used for data, but the next 16KB is also used (for stack and uninitialized buffers). When using the ROM API, only the first 16KB is used.

For this watchdog test case, I think we only need to skip the first 16KB, because this is used as the data segment in ROM code and might be cleared to zero. The latter 16KB is used as stack and uninitialized buffers, which has no impact on the watchdog test case. Do you agree ?

@butok
Copy link
Contributor

butok commented Nov 3, 2025

The Boot ROM uses the first 32KB of the RAM during boot.

So I would reserve/skip 32KB.

@AllenZhang-NXP AllenZhang-NXP force-pushed the bugfix/98282-tests-drivers-watchdog-wdt-basic-api branch 2 times, most recently from 6a14bc3 to 1f6a150 Compare November 3, 2025 09:38
@AllenZhang-NXP
Copy link
Contributor Author

Updated the overlay file to bypass first 32KB SRAM which is used by BOOTROM.
west build -p=auto tests/drivers/watchdog/wdt_basic_api -b frdm_mcxw23 -T drivers.watchdog.nxp_mcxw2xx_bypass_first_32k
west build -p=auto tests/drivers/watchdog/wdt_basic_api -b mcxw23_evk -T drivers.watchdog.nxp_mcxw2xx_bypass_first_32k

The first 32KB will be used by BOOT ROM.
Added board shared sram bypass first 32KB overlay.
The overlay configure shall bypass first 32KB memory to avoid
being clear during system startup.

Signed-off-by: Allen Zhang <[email protected]>
@dleach02 dleach02 force-pushed the bugfix/98282-tests-drivers-watchdog-wdt-basic-api branch from 1f6a150 to 7c02bf4 Compare November 4, 2025 21:21
@dleach02
Copy link
Member

dleach02 commented Nov 4, 2025

@AllenZhang-NXP I rebased your PR to main. Lets see if it clears the CI failure.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Nov 4, 2025

@dleach02 dleach02 added this to the v4.3.0 milestone Nov 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Boards/SoCs area: Tests Issues related to a particular existing or missing test area: Watchdog Watchdog platform: NXP MCU platform: NXP NXP

Projects

None yet

Development

Successfully merging this pull request may close these issues.

tests: tests/drivers/watchdog/wdt_basic_api: frdm_mcxw23/mcxw236: failed: Unknown Error

5 participants